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Figure 5. System Parameter File page 1 



1 <?XML VERSION-" 1.0"?> 

2 <GENERAL> 

3 <D0MAIN5> 

4 < DOMAIN NAME- "XML" > 

5 < STYLK KEY-"ELEM" 

6 ~ LAB£L-"Eleinent"X%T%A>%V%C{/%TX/ STYLO 

7 <_STYLB KEY- "PI" 

8 LABEL-" Processing Instruct ion"X?IT%V%A?X/_STYLE> 

9 <_STYLE KEY* " COMMENT " 

10 LABEL»"Can*nent"X'— • IV — ></STYLE> 

11 <_STYLE KEY-^TEXT" 

12 LABEL— 'Text" >%V</_STYLE> 

13 <_STYLE KEY* "C DATA** 

14 LABEL— "C DAT A" XI (CDATA(IVJ | ></_STYLE> 

15 < EMPTY EMPTY_STYLES-"ELEM"XiT%A/x/EMPTY> 

16 <HEADER> ~ 

17 <?xml vers ion-** 1.0"?X/HEADER> 

16 <CXTENSI0N SYSTEM-"e:\dev\agentviev\R«laa*e\AgentView" 

19 LABEL-"Vl«w"/X/DOMAIN> 

20 < DOMAIN NAME- "Key- Value"> 

21 <_STYLE KEY--ELEM" 

22 LABEL-" Element" >IT-"1V«C</ STYLE> 

23 <HEADER> 

24 <DOCTYPE /X/HEADBRX/D0MAINX/DOHAINS> 

25 <EXEC TYPES> 

26 <EXEC_TYPE KEY- "SQL" 

27 "LABEL-" SQL-/ > 

28 <EXEC_TYPE KEY- "ADO" 

29 ~LABEL-"ADO"/> 

30 <EXEC_TYPB KEY-" SHELL" 

31 LABEL-"Shell*7> 

32 <EXEC TYPE KEY-" JOIN" 

33 "LABEL-" Join"/x/EXEC_TYPESX/GENERAL> 

34 <DEFINITIONS> 

35 <DEFAULT_OUTPUT_FONT_SI2E>24</DErAULT_OUTPUT_PONT - SI2E> 

36 {DEFAULT OUTPUT FONT>Courier New</DEFAULT_OUTPUT_?ONT> 

37 <ATT R_COL_LAB EL~S E P> I </ ATTR_COL_LABEL_SE P> 

38 <ATTR_EXEO_EXBC</ATTR_EXEC> 

39 <SPLIT H0RIZ>1< /SPLIT HORIZ> 

40 <NORMALIZE_NAME_REPLACE_CHARS> ./$</ NORMAL I SE_NAME_REPLACE_CHARS> 

41 <NORhUU,IZE_WVME_MAKE_UPPER>0</NORMALIZE_NAME_KAKE_UPPER> T 

42 <XML_CHAR_MAPX-(>-l </XML_CHAR_MAP> 

4 3 {TREE VIEW FORNAT>Type %T, Attrs: %A, Value-iV</TREE_VIEN_rORMATX/DEriNITIONS> 

4 4 <VOCABULARIES> 

45 <VOCAB KEY"** ALL" 

46 LABEL--A11"> 

47 {attribute namc-"ID"/> 

48 attribute name-*_JOIN KEY"/> 

4 9 {attribute name-"_JOIN~LABEL"/> 
50 {attribute values»"Outer Inner- 
Si pr«sence-"IMPLIE0" 

52 a tttype-" ENUMERATION" 

53 nam«-"_JOIN_TYPE" 

54 default-*OuterV> 

55 {attribute name-"_CASE"/> 

56 {attribute name-"2swiTCH"/> 

57 {attribute narae-"_SORT_BY #, /> 

58 {attribute values-" YES NO" 

59 presence-^IMPLIED" 

60 a tttype-" ENUMERATION" 

61 name-"_CHIL0REN_THREADS" 

62 deJTault-"YES"/> 

63 {attribute values-"YES NO" 

64 presence-" IMPLIED" 

65 atttype*" ENUMERATION" 

66 name-"_SKTP" 

67 default-"YES"/> 

68 {attribute value«-"YBS NO" 

69 presence-" IMPLIED" 

70 a tttype-" ENUMERATION" 

71 name-" HIDE VALUE" 



FIG. 5 

System Parameter File page 1 
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Figure 5. System Parameter File page 2 



72 default-" YES V> 

73 attribute valuea-"DAO ODBC ADO XML XOF" 

74 pres«nc«-"IMPLIED" 

75 »tt typo- "ENUMERATION" 

76 name-" OBTYPE" 

77 dofault-"ODBC"/> 

78 <attribute name-"_0BID"/> 

79 <attribute values* "YES NO XML" 

80 preaence-* IMPLIED" 

81 at ttyp a—* ENUMERATION** 

82 name-" PARSE" 

83 default-"YES"/> 

84 <attribute name-"_IMPORT"/> 

85 <at tribute name«"_MAX_ROWS*/> 

86 <attribute valu«»-"XML ITD XDf TEXT" 

87 presence-"IMPLIE0" 

88 a tt type- "ENUMERATION** 

89 nam«-"_IMPOftT_TY PE" 

90 default-"XMLV> 

91 <elementTyp« id-"BELL6VUE"> 

92 <any/X/el«mentType> 

93 <el*mentType id="REDMOND"> 

94 <any/X/elementType> 

95 <«lementType ld«*SEATTLE"> 

96 <any/></elementType> 

97 <elemenCType id-"FORSALE"> 
9B <any/x/elementType> 

99 <elementType ld-"DBDEFINITION"> 

100 <string/x/elementType* 

101 <elementType ld-"DBJOIN"> 

102 <any/x/al«m»ntType> 

103 <elementType ld-"INPUT"> 

104 <string/x/«lementType> 

105 <elementTyp« Id-" PROBLEM" > 

106 <any/></elementType> 

107 <Bl«mentType ld-"GENERAL"> 

108 <any/x/el«m«ntType> 

109 , <elementType ld»"CUSTOMER ,, > 

110 <any/x/elementType> 

111 <olem«ntTypc id«"FROPERTr*> 

112 <any/X/elementType> 

113 <eletiwntType Id-" CONTACT" > 

114 <any/X/elementTypa> 

115 <elementType Id- " COMPONENT* > 

116 <any/X/elementTyp*> 

117 <el erne nt Type id-"AgentLogout"> 

118 <any/x/elementType> 

119 <elementType id-" Agent Ready "> 

120 <any/X/elementType> 

121 <elementType Id- "AgentMot Ready" > 

122 <any/X/elBmentType> 

123 <elementType ld-»AgentNotBusy"> 

124 <any/X/elementType> 

125 <elem«ntType id«*E*tablieh«d"> 

126 <any/x/elementType> 

127 <«lementType id-"CallInbound"> 

128 <any/></elementTyp«> 

12 9 <elementType id-"CaliOutbound"> 

130 <« ny/ X/ element Type > 

131 <elementType ld-"CallWork-> 

132 <any/><:/el«ro«ntType> 

133 <elementType ld-"Relea«ed"> 

134 <any/X/« lament Type> 

135 <elementType id-"CaliHoid"> 

136 <any/X/elementType> 

137 <CLEMENTiJ> 

138 < 08 DEFINITION ICON^DEX--^" 

139 LABEL-"Oataba«a"/> 
14 0 <INPUT ICON INDEX-"143 W 

1 4 1 LABEL-" Input Parameter" / ></ELEMENTSX/VCCAB> 

14 2 <VOCA8 content-*CLO$E0" 
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Figures. System Parameter File page 3 



143 KEY— " PRO B" 

144 LABEL-" Problem Log"> 

145 <attribute name-"_JOIN_KEY V> 

146 <attrlbute name--~JOIN~LABEL"/> 

147 attribute values-"Outer Inner" 
14 8 presence-" IMPLIED** 

149 at t type- "ENUMERATION" 

150 name- w _JOIN_TYPE- 

151 d«fault-"Outef7> 

152 attribute name-"_CASEV> 

153 <attribute name-"~SWITCH ,, /> 

154 attribute nam«-"Is° RT _ BY " /> 

155 cattribute values- "YES NO" 

156 pr««tnc»-"IMPLIED" 

157 a tttype-" ENUMERATION" 

158 name-" SKIP" 

159 default-"YES"/> 

160 <attrlbute valuea-"YES MO" 

161 presence— "IMPLIED" 

162 a tttype-" ENUMERATION" 

163 name-" HIDE VALUE" 

164 default-"YES"/> 

165 <elementType ld- w DB DEFINITIONS 

166 <atrinq/X/elementType> 

167 <elem«ntTyp« ld-"INPUT"> 

168 <strino,/X/eleinentType> 

169 <elementTyp« id-* PROBLEMS 

170 <any/X/elementType> 

171 <eletnentType Id— H LOGOUT" > 

172 <any/x/elementType> 

173 <elementType ld-"READY"> 

174 <any/X/«lem«ntTyp€> 

175 <elem«ntType ld- w NOTBUSY"> 
17 6 <any/x/elementType> 

177 <elementType Id-" NOT READY" > 

178 <any/x/ele(nentType> 

179 <ELEMENTS> 

180 <DBDEFINITI0N IOON_INDEX«"142" 

181 LABEL-" Da t aba ae"/> 

182 <ZNPUT ICON_INDEX-"143" 

183 LABEL* ''Input Pa remoter" /X/ ELEMENTS ></ r VOCAB> 

184 <VOCA8 DTD-"news.dtd" 

185 KEY-^SCRIPTINGNEWS" 

1 86 LABEL— "Script IngNews-DTD" / ></VOCABULARIES> 

187 <ELEMENTS> 

188 <BELLEVUE ICON^NDEX-"^" 

189 LABEL-" Be llevue"/> 

190 <CUSTOMER ICON_INDEX--138" 

191 LABEL-" Cus tome r"/> 

192 <DBDEFINITION ICON_INDEX-"142" 

193 LABEL— "Database" /> 

194 <FORSALE ICON INDEX-" 139" 

195 LABEL— "For Sal«"/> 

196 <GENERAL ieON_INDEX-M45" 

197 LABEL— "Genera !"/> 

198 <INPUT ICON_INDEX--143" 

199 LABEL-"Input P«raraeter'7> 

200 <DBJOIN ICON_IND£X-"14 4" 

201 LABEL-"Joln Chlldren"/> 

202 < PROBLEM ICON_INDEX-"147" 

203 LABEL- "Problem* 
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// this code called from within Process Element, at the point where we need to chock If 
JOIN is requested. 

// execute any intermediate level nodes 

If (aExecType.CompareNoCaae|TOKEN_JOIN) — 0) ( 
CT re ©It em »pBaaeItem, *pJoinItem; 
CString sJoln; 
CString sJoinKey; 
CString aJolnLabel; 
JoinType jolnType; 
POSITION basePos; 

// parameters for the Join: 

// JOIN TYPE: INNER, OUTER 

// JOINJCEY: the key used to check the join condition 

// JOIN~LABEL: the new key for the joined cow 

// find join parameters 

SearchAttrlbuteValue (CString (TOKEN_JOIN_TY PE) , a Join) ; 
If (sJoin.CotnpareNoCase{TOKEN_JOIN~OUTERJ 0) 
jolnType ■ OuterJoln; 

else 

jolnType - InnerJoin; 
// get join key 

SearchAttrlbuteValue (CSt ring (TOKEN_JOIN_KEY ) , sJoinKey) ; 
// get join label 

SearchAttrlbuteValue (CSt ring (TOKEN_JOIN_LABEL) , aJolnLabel ) i 

// take the first child aa the source of the join, 
// join the second 

baaePos - m__childList .GetKeadPosltlon ( ) ; 

pBaseltem - (CTreeltem *J m_chlidList .GetNext ( basePos I; 

while (basePos !- NULL) { 

pJoinltero - (CTreeltem M m_childLiet .GetNext ( basePoa ); 

pBaaeltera • pBaseXt em->JoinTp Join I tem, s Jo In Key, aJolnLabel, jolnType) ; 

ASSERT VALID(pBaaeltem); 

) 

// now prune all children and replace with the new base 
for I pos - m_chUdLlst.GetHeadPositlon() j (prevPos - pos) 1" NULL; ) ( 
pChlldltem - (CTreeltem *) m_ehildLlst -GetNext < pos )j 
m_childList . RemoveAt ( prevPos ) ; !/ remove what's at prevpos 
delete pChLldTtem; 



// add the generated children to this node 

for (pos - pBaseIcem->ra_chlldList .GetHeadPosltion ( ) ; (prevPos - pos) I- NULL; I ( 
pChlldrtem - (CTreeltem *) pBaseItem->m_ch lid List .GetNext (pos); 
pChildl tem->m_pParent - this; // reset the parent 
ASSBRT_VALID(pChlldItem) ; 
m_childLl5t.AddTail(pChlldIteml ; 

pBaeeIteir->m_childLlst.RemoveAt ( prevpea ); // remove what's at prevPos 
ASSERT VALIDTthis); 

J 

) // end TOKEN_JOIN 



ifntntttun/mttntuummfttmuunmtttmt/ifnttiitnnmnm 

If Join - join the Input subtree children with the current subtree's children, 

// returning a new subtree as the result. The resulting parent la a copy of 

// 'this', with joined children 

CTreeltem *CTreeItem: : Join (CTreeltem *pJolnTree, 

CString sJoinKey, // key to Join on 

CString eRowLabel, // new row label 

JolnType jolnType) 

I 

POSITION posO; 

CTreeltem *plten>0, "pNcwSubt ree, *pSubtreeO, *pSubtreel; 
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ASSERT_VALID( pJoinTree) ; 

// operate on Che longest List as the source 

if |m_childList.GetCount < 1 >* pJoinTree->m_childLlat .Get Count () I ( 
pSubtreeO - this; 
pSubtreel - pJoinTree; 

I 

else { 

pSubtreel - this; 
pSubtreeO - pJoinTree j 

I 

// create the Join subtree to hold results 

pNewSubtree - new CTreeltem (m_sKey, m_sValue, m_attrLlst, m_j)Parent); 
// now do llstO JOIN liatl 

for (poeO - pSubtreeO->m_chlldLlet.GetHeadPoeition(); posO I- HULL; I { 
CTree! ten *pKeyItem, * pTargetltem, *pMergedItam| 
pltemO - (CTree Item *) pSubtreeO->»_chlldList .GetNext (posO) ; 
// find the value of the row's Join Key Item. 
pKeyltem - pItemO->SearchSubtrae ( 

(CString) TOKENJrtlLDCARD + + aJoinKey, TOKEN_WILOCARD| ; 

// as long as we find a join key, try and join 
If (pKeylterr.) ( 

// search the join subtree for w */VJOIN_KBY/pKeyItem->m_a Value" 
if ( (pTargetltem - pSubtreel->SearchSubtree( 

(CString) TOKE M_W I LDCAR D + 

+ TOKEN_WI LDCAR 0 t */" 

+ aJoinKey, 

pKe y 1 1 era- >ra_s Va 1 ue | ) !- NULL) ( 

// we have a join on this "row" 

CTreeltem *pNewItem — new CTreeItem(*pItemO ) ; 

pNewltem->m_pPacent - pNewSubtree; // set the parent 

if ( ! sRowLabel. IsEmptyi ) ) 

pNewIteni->m_sKey ■ sRowLabel; 

// merge for the join. Note that pTargetltem points to the 
// item containing the join key. We want to join at the row 
// level, which is the parent of this node. 
pMecgedltem - pNewIten*>Harge(pTarg«tItem->n_pPacent) ; 
delete pNewItem; 

pM erg edit era ->R amove Dupa I J ; // remove any dup children 

// add the joined child to the new parent 
pMergedItera->m_pParent » pNewSubtree; 
ASS £RT_VALID{pM erg edit era) ; 

pNew£ubtree~>m_chlldLiat.AddTall (pMergedltem) ; 

} 

else if (joinType OuterJoln) ( 

CTreeltem *pKewItem - new CTreeltem ( *pltem0) ; 
pNewItem->m_pParent - pNewSubtree; 
pNevItem->m a Key » sRowLabel; 
pNewSubtree->m_chlldLiat.AddTail (pNewItem] ; 

I 

) 

else if (joinType — OuterJoin) { 

CTreeltem *pNewltem - new CTreeItem(*pItemO) ; 
pNewItem->m_pParent - pNewSubtree; 
pNew!teiP->m - sKey - sRowLabel; 
pNewSubt ree->m_cht ldLlat . AddTail (pNewItem J ; 

> 

\ 

// return the joined tree 
ASSER7_VALID( pNewSubtree | ; 
return pNewSubtree; 
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///////////////////////////////////////////////////////////////////////////// 

// Merge - Merge 'this' children with the Input children, returning a newly 
// created subtree 

CTreeXtem *CTreeIteir.: : Merge (CTree It em +pMergeTree) 
t 

CTreeltem *pTreeItem - new CTreel tern (*t his ] ; // copy current tree 

POSITION pos; . 

CTreeltem *pChildItem, *pNewChild; 
// copy each subtree to target 

foe (pos ■ pMergeTree->n_chlldUst.GetHeadPosltlon(); pos !- NULL; ) { 
pChlldltent - {CTreeltem *J pMergeTree->m_chlldLi*t .GetNext ( pos ); 
pNewChild - new CTreeltem ( *pChildI tern) ; 
pNewChild->ir _pP*rent - pTreeltem; 
pTreeItem->ir childLiet . AddTail (pNewChild) ; 

) 

return (pT reel tern) ; 

) 

/////// f///////////////S /////////////////////////////// ////////////////////// 

// Remove Dups - remove and delete duplicate children. Two children are 
// considered dups if they have the same sKey f sVslue, and sAttributea 
VOID CTreeltem: : Remove Dups ( | 

{ 

POSITION pos, posl, prevPos; 
CTreeltem + pTreeltem, *pTargetItem; 



// for each child, remove any dup later in the list 
for (pos - m_childLlet .GetHead Posit ion () ; pos I- NULL; ) ( 
pTargetlten - (CTreeltem *) m_childList .GetNext ( pos ); 

// see if target is anywhere else in list, remove if so 
posl - pos; 

while {(prevPos - posl) !- NULL) | 

pTreeltem - (CTreeltem *) m_childList .GetNext ( posl ); 

if (pTreeItem->m_sKey — pTargetItero->ra__sKey 

ti pTreelt em- >m_a Value " pTarget Item->m_sValue 
&fi pTreeIt«m->m_attrList pTarget It em->ro_at trLlst ) ( 
m_chlldList . RemoveAti prevPos ); // remove at prevPos 
delete pTreeltem; 

\ 

) 

) 

1 

///////////////////////////// ////////////////////////////////////////////// f/ 
// SearchSubtree - find the first tree item in the subtree given the path 
// The subtree path may contain the wildcard character '**, which Indicates 
// all children of that node should be searched. 

// Example: SearchSubtree fWCUSTJtD", "000128") searches all children 

// of the current subtree 'this* for the first child with key 'CUST ID 1 and 

// value '000128'. 

CTreeltem * CTreel terr. :: SearchSubtree (CStrLng sSearchPath, CStrlng sValue) 
( 

BOOL pathBnd; 
CStrlng sKey, sRemains; 
int lLoc; 
POSITION pos; 

CTreeltem *pchildltem, *pFound; 

// search all children for the given path component 
iLoc - sSearchPath. Find (SLASH CHAR); 
if (iLoc >- 0) ( 

sKey ** sSearchPath. Left (ILoc) ; 

sRemalna - sSearchPath. Hid (ILoc + 1); 

path End - FALSE; 

) 
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else { 

sKey - sSea rchPath; 
pathEnd - TRUE; 

I 

//'if we're at the end of the path, check to aee if this node is it. 
if (pathEnd J ( 

// we have a match if: 

// 1) exact match, 2} a Key is wildcard and valuo matches, 
// 3) aKey matches and sValue Is wildcard, 4) both wildcard 
if ({m sKey — aKey C* io_aVelue — aValueJ 

I |~(sKey — TOKEN WILDCARD it m_aValue — aValue) 

|| (m sKey — aKey 4* sValue — ~TOKEN_WILDCARD| 

| | (sKey — TOKEN_WI LDCARD ti sValue — TOKENJflLOCARD) ) 

return this; 

) 

// for each child, remove any dup later in the liat 
for (po* - m_chlldL 1st. Gat Haad Position!); poa I* NULL; ) { 
pChildltem - (CTree I tent *) ra_chl IdLiat . GetNext { poa )t 
if not the and of path, so keep searching if this la allowable path 
if [sKey — || aKey — pChildItera->in_aKey) { 

If UpFound - pChildItera->SearchSubtree(aRenaina,oValue) ) !• NULL) 
return p Found; 

) 

) 

// if we cot here and we* re at the end of the path, we didn't find It 
return NULL; 
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///////////////////////////////////////////////////////////////////////////// 
// find and replace all substitution strings, A substitutable token has the form 
// HREF, ft! represents the token prefix, which can be changed by setting the 
// parameter TOKEN PRETIX . REF is an internal document reference of the Corn 
// <complex-path>.<attr>. The character ls the attribute specifier, and can be 
// changed by setting the ATT R_DESIG NATO R system parameter. 
// See CTreeltem: ;GetTreeItet»Comple*Path for complex-path definition. 
//If <coreplex-path>. ls omitted, /INPUT. <attr> ls assumed, and the token 
// evaluates to the attribute value of <attr> In the INPUT element. If a path 
// is given with no <attr>, then the token evaluates to the value of the resulting 
// element. Some examples: II FILENAME is transformed to /INPUT. FILENAME, which 
// evaluates to the value of the FILENAME attribute In the INPUT element. 
// ../ITEM. 10 evaluates to the value of the 10 attribute In the current parent's 
// ITEM element. 
^CStrlng CTreeltem: :Substitutlon(CString tinput, bool bXeyMap) 

L { ^402 



400 



CStrlng sRemains - input; 
CSt ring sToken, sResult; 
CStrlng sDef, aValue; 
CTreeltem *pDefItem, *pRoot* 
bool bReplaceSpeciai*FALSE; 
_TCHAR cReplace; 
lnt iLoc*»0, iLocl, len; 
CStrlng sAttr, aPath, sLastf 



len m sRemains .GetLengthf ) ; 
sResult - input; 

// search for the INPUT element 
pRoot ■* TreeRoot 1 ) ; 

// parse the input string for replacement tokens 
do ( 



sRemains ■ sResult; 
iLoc - sRemains. Find (TOKEN_PRE FIX); 
If (iLoc < 0) // all substitutions performed 
break; 



ILOC TOKEN_PREFIX_L£N; 
sRemains - sRemains.Mld ( LLoc) ; 



// get end of line or space to end this token 
sToken - sRemains . Spa nlncluding ( PARAM_CHARS) ; 

//if this is single name token, put In special-case defaults 
// this Ls a deprecated feature that will soon go away* 
If (sToken . SpanExcludlng (TOKEN_NAME_CHARS) . IsEmpty( | ) ( 
sAttr * sToken; 

pDeflteir - pRoot->FindChildElement (T0KEN_INPUT) / 

) 

else ( 

// Split token into path-last-attr parts 
// find the last path component 

if ({iLocl - sToken. ReverseFind(SLASH_CHARJ 1 >- 0) | 

sLast - sToken. Mid (ILocl t ; // note: don't discard V 
sPath - sToken. Left( iLocl); 

\ 

else ( 

sLast - sToken; 
sPath - 

J 

// split attr from sLast 

if ((ILocl - s Last . Reverse Find (ATTR_DE5 1 GNATOR I ) >* 0) t 
sAttr - aLast.Mid(lLocl*l}; 
sLast - sLast. Left! ILocl I ; 

> 

else ( 

sAttr - 
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I 

// now put che path back together 
oPath - sPath + sLast; 

// get the tree item. If full path given, search from root, otherwise 
// relative path from current tree Item 
If |SPath(0) « SLASHCHAR ) 

pDefltem - pRoot-X3etTreeItemComplexPath(sPath) ; 

else 

pDefltem - GetTreeltemComplexPath (sPath) ; 

) 

if (pDefltem) { 

if get the substitution value 
if [sAttr. Is Empty <) ) 

sValue » pDef Item->m_sValue; 

else 

pDef Item->m_ettrLlat . Lookup (eAttr, sValue) j 

> 

else 

sValue - m "t // blank it out 

// found It, so make the substitution 
// put the sub string into the original 
sResult - a Result .Left ( lLoc-TOKEN_PREFIX_LEN ] 
+ sValue 

+ sRe suit. Mid (lLoc + sToken.GetLength ( ) ) j 
I while (TRUE); 

// perform the character mappings, if r«qu«st«d 
if (bKeyMap) ( 

// substitute any mapped characters 

CSt ring sMap; 

sMap. Format ( XML_CHAR_MAP ) ; 

// do basic error checking 
if (sMap.GetLengthO J ( 

if (sMaptOJ I- D£riNE_CHAR it sMap[sMap.GetL«ngth( ) -1 ) !- DEFINE_CHAft) ( 

int IMap; ~ 

len - a Remains .GetLengthf ) ; 

s Remains » sResult; 

do ( 

IMap - sMap.Find{DEFINE_CHAR); 
If (iMap <- 0) 
break; 

// set flag to replace special chars 

If (sMap|iMap-l) — XML_S PE CI AL_R E PLACE_ FLAG J ( 

bReplaceSpocial - TRUE; 

cReplace - aMap | iMap+1 ] ; 

I 

else { 

// replace all instances 
do ( 

lLoc * sReraains. Tind (eMapl IMap- 1) ) ; 
if (lLoc < 0) // all substitutions performed 
break; 

sRemains.SetAt<lLoc,«MapUMap+lJ ); 
) while (TRUE); 

} 

s Map - sMap.Mid(iMap+2); 
) whLle (TRUE) ; 

J 

I 

// replace all special chars if indicated 
unsigned long ch - XML_SPECIAL_CHAR_VALUE; 
If (bReplaceSpecial > ( 

for (iLoc - 0; lLoc < sRemaina.Getlength ( J ; lLoc+O 
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if (< unsigned) sRemalns (iLoc) > ch) 
sRemalns. SetAt (ILoc, cReplace) ; 



return sRemalns; 

I 

///////////////////////////////////////////////////////////////////////////// 
// Get the first subtree at the specified complex-path. A complex-path 
// has components of torn /KEY : IO"VALlVSUBKEY: ID*"999V • - • Only a single 
// attribute is supported currently, but this may be expanded in the future 
// to support any number of keys. As a shortcut, if attribute name is left out, 
// 1 ID 1 is assumed, e.g. above example la same as /KEY: "VALIVSUBKEY : "9 99" . 
// The path may be relative, using path component '.'to represent the current 
// directory, ' to represent a parent directory. Leading •/' represents 



r 



f/ the root of the tree. ^410 
// Return MULL if not found. f 



CTreeltem *CTreeIteir : :GetTreeItemComplexPath(C3tring aPath) 



4£)/ BOOL pathEnd; 

CStrlng sKey, a Re ma ins, sldAttr, sldValue; 
Int iLoc; 

Int i Index, i Chi Id; 

BOOL bAttr- FALSE, blndex- FALSE; 

POSITION pos; 

CTreeltem *pchildltem, *pFound; 
// check for reference to parent 

if (sPath[0) — DOT_CHAR it 9Path[ii — DOT_CHAR) { 
ASSERT VALIC(m_pP*«nt); 
sPath - sPath.Mld[2>; 

return m_pPa rent->GetTreeItemComplex Path (s Path) ; 

I 

// search all children for the given path component sKey. Strip leading •/', './' 
if (aPath[0) — OOT_CHAR) 

sPath * sPath.Mid (1); 
if (sPatMOJ SLASH_CHAR) 

sPath - sPath.Mid jl); 
1LOC - sPath. Find{SLASH_CHAR| ; 
if (iLoc >- 0) ( 

sKey « s path. Left (iLoc) ; 

sRemains - s Path , Mid { iLoc + 1|; 

pathEnd * FALSE ; 

1 

else { 

sKey - sPath; 
pathEnd - TRUE; 

) 

// within the path component sKey, separate out the identifying attr-value pair(s) 
if ({iLoc - sKey. Find (ATTR_DESIGNATOR J ) >- 0) ( 
bAttr - TRUE; 

sldAttr - sKey.MidULoc+l); 
sKey - sKey. Left ( ILOC) ; J 

// find attribute value. If ve have single value Instead of "ID-val M form, 
// then assume the attribute is "ID", and only value Is supplied. 

if [(ILoc - SldAttr. Find (EQUAL_CHAR) ) >- 0) { 
sldValue - sldAttr. Mid < iLoc+1 ) ; 
sldAttr » sldAttr. Left (iLoc); 

) 

else { 

sldValue - sldAttr; 
sldAttr - ATTR_ID; 

> 

StripQuotes (sldValue) ; 

) 

else it (ULoc «• sKey. Find ( INOEX_DESIGNATOR) ) >» 0) ( 
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// hash mark indicated a 1 -based Index 

CSt ring slndex; 

blndex - TRUE; 

slndex * sKey .Mid ULoc+1 ) ; 

5 Key - sKey.Left tiLoc) ; 

I Index * a to I (a Index) ; 

I 

else 

bAttc - FALSE; // no attribute search at this level 



j f 

// for each child, search for watch and proceed with lower level search 

// If children Are indexed on ID, lookup the child directly, otherwise, search 

// children. 

If (m chlldLookup) ( 

pChildltem - GetKashedChi Id (sldValue J ; // ID Is Wash value 

// not the end of path, so keep searching If this is allowable path 
if ibAttrl { 

If (sKey pChlldItem->m_slCey it pChlldItei»->n_attrList (sldAttrJ — 

sldValue) { 

if (pathXnd* 

return pChildltem; 

else If ((pFound - pChlldItem->GetTreeItemCODnplaxPath(sRemalns ) ) 1- NULL) 
return pFound; 

\ 

) 

else t // ignore attributes 

if (sKey pChildItem->m_sKey) { 
if {path End) 

return pChildltem; 

else if [(pFound - pChildltem- >GetTr eeltemComploxPath [sRema ins ) ) I- NULL) 
return pFound; 

) 

) 

) 

// otherwise do a sequential search 
iChild - 0; 

for (pos - m chl IdLlac .GetHeadPosltion( f ; pos !• NULL; ) ( 
pChildltem - [CTreeltem ♦) m_childList .Get Next ( pos I; 
// not the end of path, so keep searching if this is allowable path 

if (bAttr). ( 

if (sKey — pChildItem->m_sKey it pChildItera->m_att rList (sldAttr) 

sldValue) { 

if (pathSnd) 

return pChildltem; 

else if ' (pFound - pChildItem->GetTreertemComplexPath (sRemains ) ) I- NULL) 
return pFound; 

) 

) 

else Lf (blndex) { 

// if this is the right key, increment count and check if we're there 
if (sKey — pChildItem->m_sKey l£ t+lChlld — ilndex) ( 
if (pathEnd) 

return pChildltem; 

else lf {(pFound - pChlldItem->GetTceeIteinComplexPath (sRemains ) ) !- NULL) 
return pFound; 

I 

1 

else ( // ignore attributes, get the first of this key 
if (sKey — pChlldItem->m_sXey) ( 
if (pathlndl 

return pChildltem; 

else lf {(pFound - pChl Id Item->GetTreeItei»ComplexPath (sRemains H I* NULL) 
return pFound; 

I 

) 

) 

// if we got here and we're at the end of the path, we didn't find it 
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return NULL; 

) 
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DYNAMIC, HIERARCHICAL DATA 
EXCHANGE SYSTEM 

CROSS REFERENCES TO RELATED 

APPLICATIONS 5 

This application claims the benefit of Provisional Patent 
Application Ser. No. 60/077,259, filed Mar. 9, 1998. 

FIELD OF THE INVENTION 3o 

The present invention relates to networked computer 
systems in which a plurality of interconnected computer 
systems exchange data. 

BACKGROUND OF THE INVENTION 15 

The present invention relates to computer systems inter- 
connected by a network, suitably configured to transfer data 
between one another. A computer system connected to the 
network processes data from a plurality of data sources. A 2Q 
data source can be an input device attached to the computer 
system, or can be a storage device, memory, database, or 
other computer system attached either locally or remotely to 
the computer system via a network. In the network of 
computers, at any given time, a computer system may ^ 
assume a specific role, relative to the processing of data. A 
computer system that sends a request for data from another 
computer system is said to be a Client system 1. The 
computer system that processes requests from other com- 
puter systems is said to be a Server system 2. When a Client 3Q 
sends a request for data to a Server, the Server may retrieve 
some of the requested data from its local resources, and 
some of the data from an External source 3 on the network. 
The Server 2 in this case acts as a Client to an External 
source 3, requesting the appropriate data, and the External 35 
source 3 acts as a Server. Thus, a computer system on the 
network may at one time perform the role of a Client, and 
at another time perform the role of a Server. 

Servers on the network are designed to satisfy requests for 
a particular type of data. For example, a database server may 40 
be designed to accept Structured Query Language (SQL) 
requests from clients. The database server will execute the 
SQL and return the resulting database data to the requesting 
client. A Hyper Text Transfer Protocol (HTTP) server (or 
Web Server) accepts HTTP request from client systems 45 
(generally Web Browsers), processes the requests, and 
returns the resulting Hyper Text Markup Language (HTML) 
to the client. In an enterprise business environment, such as 
the Information Processing environment of a large company, 
a Server system may accept requests for customer account 50 
information. A Client may send the request to the Server in 
an agreed-upon format, and the Server locates the informa- 
tion within its system or a connected system, then returns the 
customer account information to the Client. Frequently, in 
the enterprise business environment, the nature of the large 55 
systems involved dictates that the data exchange uses a 
custom data format instead of an industry standard such as 
SQL or HTML 

Large corporations often house data in a multitude of 
sources, such as a host, database, server, or other informa- 60 
tion source. Often, one computer system may need to 
retrieve data from many other systems in order to perform its 
function. Systems in this environment contain complex 
programs that understand the intricacies of interfacing to 
each system that contains a data item in need. Such pro- 65 
grams are complex to write and maintain, require great 
expense to development and modify, and are large in size 
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2 

due to the amount of code required for the large number of 
interfaces. In addition, typical systems access data 
sequentially, thus perform operations slowly more slowly 
than if data could be retrieved in parallel. More advanced 
systems perform some data retrievals in parallel, but the 
complexity of this type of system requires greatly more 
experienced programmers and testers, thus significantly 
increasing the cost of system development. Finally, the code 
developed to interface to each system and each data source 
is not easily reused in other systems in the enterprise for a 
variety of reasons. Program A may be a customer service 
application and may access servers 1, 2, and 3. Program B 
developed by another group may be a billing system that 
accesses servers 1,2, and 4. Some reasons for low success 
rate of reuse are the fact that programs perform vastly 
different functions (service vs. billing), so developers often 
do not recognize the possibilities of reusing code. Tools to 
assist in reuse are not widely used, developers are generally 
slow to be convinced that existing components will precisely 
fit their needs, and current engineering practices that empha- 
size reuse have not been widely adopted in many corpora- 
tions. In the cases where code is reused, it often is copied and 
customized by a programmer, requiring work for the cus- 
tomization and testing for the resulting implementation. 

When a Client requires data from many different sources, 
it must contain a method and apparatus to send a request to 
each Server providing each type of required data. The Client 
also must have a method and apparatus to both receive the 
response data from the Server and to make sensible use of 
the data. Likewise, a Server needs a method and apparatus 
to process requests from Clients, and return resulting data to 
them. In the typical enterprise computer system 
environment, the methods and apparatuses for both Client 
and Server must be developed, integrated, tested, and 
deployed. 

The methods and apparatuses necessary for a Client to 
usefully retrieve and process data from a Server is called an 
Interface. The code components involved in an Interface are 
shown in FIG. 3. The Client makes a request from the 
Request Code 4, which contains the method and apparatus 
to send the request to the Server and receive the result. The 
Request Code uses information from the Data Source 
Description Code 5 component located on the Client, which 
contains the method and apparatus to identify how to 
physically connect and maintain a connection to the Server. 
The Server component contains a Service Processor 6 that 
contains the method and apparatus to receive the request, 
cause the Server to process the request, then return the 
results to the Client. The Request Code for the Client 
receives the request, then identifies and interprets each 
element of information in the return using the method and 
apparatus contained in the Parsing Code 7. In total, 4 
components must be developed for each interface. 

Many computer systems use standard interface compo- 
nents such as those supporting SQL requests to database 
management systems (DBMS) to drastically reduce devel- 
opment time. Unfortunately, "many computer systems in 
large enterprise environments require interfaces customized 
for the particular Client and Server pair. For these systems, 
a large number of interface components must be developed. 
As an example, assume two client systems interface with 4 
server systems as shown in FIG. 3. Each server requires a 
Service Processor. Each Client requires Request Code, 
Server Description Code, and Parsing Code for each 
interface, therefore Client 1 requires 9 components and 
Client 2 requires 9 components, for a total of 22 total 
development components for the depicted interfaces. It is 



05/20/2003, EAST Version: 1.03.0002 



US 6,3i 

3 

possible for Clients to share interface components, for 
example, Client 2 can reuse the code developed in Client 1 
for its interface to Server 1. However, it is more often the 
case in large enterprise environments for Client 1 and Client 
2 to be developed by separate groups, and the opportunity to 
reuse the code is not exploited. 

There is a need for an interface strategy that organizes the 
implementation of the interface components, so that inter- 
face components are only developed a single time, regard- 
less of the number of Clients implementing similar inter- 
faces to various servers. This would result in fewer 
development resources being expended, because many of 
the interface components would be developed a single time, 
instead of once for each Client system. 

Client systems generally request data in a sequence of 
steps. For example, a customer service application may 
perform the following sequence of processing steps: 1) 
obtain a customer phone number from the user, 2) request 
account information such as name, address, and account 
number from a Server, 3) send request to another Server to 
retrieve current order information, 4) send a request to the 
same server to retrieve order detail information, 5) send 
request to yet another Server to request service contact 
history. Each request in the sequence requires a different 
parameter in order to carry out the request. The original 
customer account request requires the customer's phone 
number. The request to retrieve order information requires 
an account number that is retrieved with the account infor- 
mation. The request to retrieve order detail requires an order 
number, which is retrieved with the order information. The 
request to return service contact information requires an 
account number. The cumulative data comprising customer 
account, order information and service history can be said to 
be a single Data File constituting the current status of the 
customer. The specification of the contents of a Data File is 
said to be the Document Definition of the Data File. Though 
a more formal specification is required in practice, in the 
current example, the Document Definition would state that 
the Data File contains account, order, and service history 
information. A Client can thus request a single data file for 
a particular customer, even though the source information is 
stored in separate Servers. 

Szlam et al. (U.S. Pat. No. 5,675,637) describe a means 
and apparatus for obtaining and displaying data with sequen- 
tially dependent information. However, there is a need to 
automatically obtain sequences of information from a plu- 
rality of data sources where vastly different Clients are 
supported. There is a need for defining the cumulative data 
file independent of any display, rendering, or presentation 
system, so that Clients of vastly differing types can obtain 
full information without developing interface code. For 
example, a customer data file as in the above example would 
be useful for a desktop client, a browser-based client, an 
Interactive Voice Response (IVR) unit or Voice Response 
unit (VRU), a hand-held computer, an invoice printing 
system, and a vast assortment of other uses. Many servers 
provide conglomerations of data in a predetermined format. 
But since different types of clients have different formatting 
needs, there is a need for the information in the resulting data 
file to be formatted according to client preference, without 
having to create a new Document Definition for the data file. 
If a client has a particular format requirement, there is a need 
for the data file to be made to conform to this new format for 
this client, and for said new format to be further available to 
other clients upon request. Hie ability to render the same 
information in different formats is enabled by abstracting the 
information itself from the format of the information. 
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Current DBMS Servers satisfy requests for data that is 
generally row-based. Row-based data is appropriate for 
clients in many instances, such as requesting data that will 
populate a visual table on a display screen. Often, a Client 

5 desires more complex information, as in the case of the 
customer Data File in the above example. A DBMS cannot 
process a request for an arbitrarily complex hierarchy in a 
single request, because requests to a DBMS are row-based. 
Instead, multiple requests to the Server are required to obtain 
data representing an arbitrarily complex set of data. There is 
a need for data servers to support arbitrarily complex 
hierarchies of data. International standards such as those 
defining SGML and XML support data file formats that 
represent arbitrarily complex hierarchies of data. Hierar- 
chies can, of course, represent rows of data just as a DBMS 
does, plus other arbitrary sets of data. 

Current Servers supporting delivery of Data Files gener- 
ally retrieve the Data File from a source, or generate the Data 
File in code, then return it to the Client. The resulting Data 

2Q File is fixed in size and information content, regardless of 
whether the client needs the entire set of information. For 
clients requiring less than the entire set of information, this 
very inefficient, as unneeded data is generated, formatted, 
and transmitted to the client. The client must read and parse 

^ the entire Data File, There is a need for clients to be able to 
flexibly select only those portions of the Data File that suits 
their particular purpose at the time. 

Current DBMS' s are Servers that act on data requests of 
clients. One advanced data manipulation feature of these 

30 systems (Oracle, Sybase, Informix, Microsoft SQL Server) 
is to perform a join operation on table data. Oracle is one 
example DBMS that allows a join across data tables on 
different Servers, even servers running different vendor's 
DBMS. But the join is limited to row-based tables, with the 

35 result of the join being row data. 

There is a need for Clients to be able to request a join of 
data that has rich, hierarchical information, such as the 
customer Data File in the above example. The join operation 
should also not be constrained to operate on a particular 

40 source of data, such as a DBMS, but rather should work on 
data from any source whatsoever. 

Current Servers can easily handle Data Files that are 
completely static. However, if some or all of the data file is 
dynamic, an intricate program must be developed to produce 

45 the dynamic portions and insert them appropriately into the 
Data File. Microsoft's Active Server Pages and Allaire's 
Cold Fusion are examples of systems that simplify mixing 
dynamic with static data for internet-based Data Files. 
However, these systems do not provide the capability to 

50 generate arbitrary levels of hierarchical data, so are limited 
in the complex data structures they can generate. There is a 
need to easily define static and dynamic portions of a Data 
File, while not limiting the complexity of the resulting data. 
Such a method is difficult to change when the needs of the 

55 .client system changes. The present invention provides a 
single data file generation engine, which can construct an 
infinite number of different types of data files. To enable the 
generation of a new type of data file, a user simply creates 
a new DDF and ensures the DDF is accessible to the Data 

60 Server. To make a modification to an existing type of data 
file, the user simply edits the DDF with the current inven- 
tions Authoring System, then the next time that type of data 
file is requested, the new format is used. All changes are 
effected with no changes to the software code, therefore no 

65 programmer must be hired to make the changes. New data 
file types and changes to existing data file types are easily 
made by an administrator. 
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OBJECTS AND ADVANTAGES 

The present invention provides several objects and advan- 
tages as follows: 

1. Interface code is organized so that a plurality of Clients 
need only one set of Request Code, Data Source 
Description, and Parsing Code. Requests are all passed 
through to a Hierarchical Data System (HDS), which 
retrieves the knowledge of how to construct the various 
dynamic portions of data, and pass the data back in a Client 
designated format. The format can be XML or other industry 
or organization standard where parsing code is readily 
available. 

2. A series of interdependent data requests can be defined 
in a Document Definition File (DDF). Elements in the DDF 
can reference previously generated data as keys, therefore 
the Client need not be concerned with ordering of requests. 
A Client can request the entirety of data in a single request, 
then process the data as it sees fit. 

3. Data is defined abstractly as a hierarchy of elements, 
able to model any data set. The generation of the data is 
independent of the output of the data to the client. The output 
format of the resulting data file can be selected by the Client, 
for example, XML, key-value pair, binary stream, ASCII 
stream, etc. Supported formats can be extended, resulting in 
an infinite number of possible formats. 

4. Conditional data element generation is provided, so that 
a Client can select portions of a data file of interest, filtering 
out those that are not of concern at a particular time. A Client 
in one instance can request that data sections A, B, and C be 
generated and delivered. In another instance, the Client may 
not need element B, so it will request the same data file with 
only data section A and C, thus saving the time and expense 
of generating, formatting, then delivering unneeded compo- 
nents. 

5. A Join operation is provided, similar to the database 
Join operation, but with extension to work against hierar- 
chical data, and data from any available source, not just 
database data. 

Further objects and advantages of the present invention will 
become apparent from a consideration of the drawings and 
ensuing description. 

SUMMARY OF THE INVENTION 

The present invention overcomes the limitations of the 
prior art by providing a highly flexible Hierarchical Data 
Server (HDS) and accompanying Document Definition 
Authoring System. The Authoring System creates Document 
Definition Files (DDF), which specify hierarchically related 
elements, each of which is capable of generating dynamic 
data. A Client sends a request to the HDS, indicating which 
DDF is desired, and a list of parameter substitutions that the 
HDS is to apply to the DDF. The HDS processes all elements 
in the DDF, dynamically generating data, then outputs the 
data in a format requested by the Client. 

FIG. 15 shows an overview of the HDS and Authoring 
System. A Client system 200 requiring data from various 
Enterprise System 202, including databases, hosts, and any 
other data source, will arrange for a new DDF 204 to be 
created using the Authoring System 203. The Authoring 
System 203 is used to define the structure and data sources 
for each element of data requested, and the parameters that 
can be used to customize the DDF 204 for any particular 
Client's purpose. The DDF 204 is stored in a location 
convenient for the HDS 201 to access it upon request. 

When the Client 200 needs the data, it sends a request 
over the interface 205 to the HDS, specifying the DDF name 
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and any needed parameters. The HDS 201 reads the DDF 
into memory, performs parameter substitution, and executes 
each element. The execution of elements is expected to 
cause a plurality of data requests to be processed over the 

5 Data Transactions Interface 206, retrieving data from the 
various Enterprise Systems 202, and returning the data over 
the interface to be placed in a DDF element on the HDS 201. 
After all elements are fully executed, the HDS 201 formats 
the resulting data into a Data File, and transmits the Data 

10 back to the Client 200 over the interface 205. 

BRIEF DESCRIPTION OF THE DRAWINGS 

A preferred embodiment of the present invention will be 
described below relative to the following figures. 

FIG. 1, Typical Client-Server Computer System shows 
the typical prior-art interactions of communicating 
computers, especially client-server systems. 

FIG. 2, Client-Server Code Components, shows typical 
prior-art code components involved in the interfacing of 
2Q computers. 

FIG, 3, Multiple Clients and Servers, shows the typical 
prior-art interactions of multiple Clients interfacing to mul- 
tiple Servers. 

FIG. 4, Preferred Embodiment of Authoring System, 
25 presents the graphical computer program layout of an 
authoring system. 

FIG. 5, System Parameter File, is an example parameter 
file used by a preferred embodiment of the invention to 
dictate processing by the Authoring System and the Hierar- 
30 chical Data Server (HDS). 

FIG. 6, Hierarchical Data Server Process, is a flowchart 
describing the processing steps of the preferred embodi- 
ment. 

FIG. 7, Process Element, is a flowchart describing the 
35 processing steps taken by the HDS to process an element. 

FIG. 8, Process Children, is a flowchart describing the 
processing steps taken by the HDS to process the children 
element of an element. 

FIG. 9, Format Memory into Data File, is a flowchart 
40 describing the processing steps taken by the HDS to format 
DDF elements after they have been executed. 

FIG. 10, Output Element, is a flowchart describing the 
processing steps taken by the HDS to format and output an 
element 

FIG. 11, SQL BuildSubtree, is a flowchart describing the 
processing steps taken by the HDS to execute an element 
containing an SQL statement, thereby dynamically generat- 
ing data for the element. 

5Q FIG. 12, CMD BuildSubtree, is a flowchart describing the 
processing steps taken by the HDS to execute an element 
containing a shell command, thereby dynamically generat- 
ing data for the element. 

FIG. 13, Join Code, is a C++ coding example, demon- 

5S strating the important steps required in the processing of a 
Join operation. 

FIG. 14, Substitution Code, is a C++ coding example, 
demonstrating the important steps required in performing 
parameter substitution prior to execution of dynamic ele- 

50 ments. 

FIG. 15, Overview of a Hierarchical Data Server and 
DDF Authoring System, is a block diagram depicting a 
portion of a network of computers suitable for practicing the 
preferred embodiment of the present invention. 
65 FIG. 16, DDF Document Structure, is a diagram depicting 
the element data structures useful in implementing the 
preferred embodiment of the present invention. 
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DETAILED DESCRIPTION OF THE 
INVENTION 

The preferred embodiment of the present invention pro- 
vides a Hierarchical Data Server which reads a Document 
Definition File upon request from a Client, performs param- 
eter substitution as specified in the Client's request, then 
visits each element in the Document Definition File, 
dynamically executing each element until all elements are 
complete, then formats the resulting data into a Data File in 



is missing, the first instance of the given Type is referenced. 
Thus, "/CUSTOMER#3/ORDER.NUM=003/ORDER_ 
ITEM.2" references ORDER__ITEM with attribute ID=2, 
which is the child of element ORDER with attribute NUM- 
003, which is the 3 rd element of Type "CUSTOMER" in the 
root level of the document. 

The previous example begins with the character */'. This 
character at the beginning of an address specifies that the 
reference begins at the root of the element hierarchy in the 



the formal requested by the Client. A Document Definition 10 document If the slash is missing the reference is a relative 

reference . If processing is currently occurring on the element 
of Type ORDER, with attribute NUM-003, a relative ref- 
erence such as "ORDER_ ITEM .2" refers to a child element 
of the current element, with Type ORDER_JTEM and 
15 attribute ID=2. As in a file system, the relative reference 
refers to the current element's parent, and "./" refers to the 



Authoring System is provided to assist in the construction 
and maintenance of Document Definition Files. 
Document Definition File 

According to a broad aspect of a preferred embodiment of 
the invention, a computer system specifies the content, 
sources, and method of generation of a collection of data and 
stores this in a file (a Document Definition File, DDF). The 
type of data that can be defined is very general and is 
restricted only in that it must fit into a hierarchical structure. 
Importantly, the DDF is not limited to information of a static 
or unchanging nature. Instead, the DDF is a hierarchy of 
elements, each of which may specify static data, or indicate 
a mechanism to fetch data dynamically. FIG. 16 shows a 



current element. If processing again is occurring on the 
element of Type ORDER, with attribute NUM=003, the 
reference "../ORDER#l" refers to the first element of type 
20 ORDER that is a child of the current CUSTOMER element. 
Replacement Operator 

Elements in a DDF can specify reference to other ele- 
ments in the DDR By prefixing a reference with the special 
replacement operator "%%", direction is given to replace the 



pictorial view of the element hierarchy of a DDF. Formally, _ <■ * 

a DDF is defined as a list of elements, where each element 25 ^™" c ^ ^An™ ^^nl^^^ 9 

is defined as consisting of the following components: ^^^ EK ^ /0 ^ DER T M ;°° 3/ °™^ 

, ^ u . l * u ITEM.NAME is a directive to replace the string "%%/ 

e^ef 3 Cter Stmg nammg tyP£ CUSTOMER#3/ORDER.NUM-003/ORDER_ITEM.2" 

with the Value component of the element with Type 

2. Value 221: a character string representing the value of 30 ORDER ITEM and ID-2. 
this element Executable Elements 

3. Attribute List 222: list of attributes represented as Elements in the DDF can be either static or dynamic, 
key-value pairs, each key-value pair consisting of: static elements are defined with element components that do 

a) Key: a character string naming the attribute not change. Dynamic elements must be executed in order to 

b) Value: a character string representing the value of the 35 generate data for the element. For example, an executable 
attribute element may generate data from a DBMS by sending an 

4. Style 225: a character string designating the output SQL statement to the DBMS. The result is a sequence of 
formatting for this element rows, each of which contain columns of data. Upon 

5. Children 223: a list of zero or more elements. execution, the original element is updated to include a child 
As indicated above, each element contains, among other 40 element for each row retrieved. For each of these child 



things, a list of zero or more elements representing the 
children elements of the present element. Thus, the mecha- 
nism is provided to build arbitrarily complex hierarchies of 
data. 

Addressable DDF Components 

Each component of each element in the DDF is addres- 
sable by specifying a complete path to the component. Since 
the DDF is a hierarchy of elements, it is convenient to think 
of components of the DDF as a file system. Just as files in 



elements, elements are constructed to contain each column 
within the row. 
The Data File 

Every element in the DDF is potentially executable. In 
45 addition, every generated child of an executable element 
may itself be executable. Thus, provisions are made to visit 
and attempt to execute every element. After an element is 
executed, its children are visited and they are executed if 
appropriately. The process continues recursively until all 
a file system can be referenced with a full pathname, so can so elements are executed. Once execution of all elements are 
elements in a DDF. For example, the path /CUSTOMER/ complete, the set of elements are formatted and returned to 
ORDER/ORDER _JTEM specifies an element of Type a client. The resulting output is called a Data File (DF). 
ORDER.JTEM that is a child of an element of Type Hierarchically Embedded Executable Elements 
ORDER, which itself is a child of an element of Type The original executable element in the previous example 

CUSTOMER. Such a path is called a reference. Whereas a 55 specified an SQL statement. In addition, it may also contain 
file system houses components of individual files, a richer a list of children elements, some of which may be execut- 
scheme is required with DDFs to address individual com- able. Upon generation of each element for the returned data 
ponents within an element. Also, although filenames are rows, the original child elements are rep Heated in these 
unique in a particular subdirectory, many children of an elements. The replicated elements may make use of the 
element can normally do have identical Types. Thus the eo newly generated elements by using relative references. As an 



addressing scheme is expanded as follows: Each path com- 
ponent can take the form <Type>#<index> or 
<Type>.<attr>=<attr_value>, where <Type> is a the ele- 
ment Type, <index> is a number indicating the sequence 
number of the element referenced, otto is an attribute key, 
and <attr__value> is an attribute value. Several shortcuts are 
allowed: if <attr> is missing, "ID" is assumed. If #<index> 



65 



example, assume the original element contained the follow- 
ing SQL statement: "select ORDER_DATE, NUM from 
orders where CUSTOMER_ID=432". This query, when 
executed on an appropriate database, will return a list of 
rows containing a date and a number, one row for each order 
in the table for the customer with ID 432. Let's assume the 
following 3 rows are returned: 
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02/27/1999 002 
03/01/1999 003 
03/02/1999 005 



This results in 3 new children for the original element, one 
for each row returned. Each of the three new elements would 
contain two generated elements, one containing the date, and 10 
one containing the order number. Let* s assume now that the 
original element has a child element. The child element is 
replicated as a child in each of the 3 generated row-level 
elements above. The original child element can be 
executable, and can also refer to the newly generated 15 
children, having foreknowledge of what will be generated. 
In particular, it may be useful to execute an SQL statement 
that generates ORDER_ITEM elements by referring to the 
generated NUM field. This SQL statement might look like 
this: "select NAME, ITEM_NUM from ORDER_ITEMS 2Q 
where ORDER__NUM=%%./NUM". At execution time, 
%%/NUM is treated as a relative reference to the child 
element of type NUM. The Value field of this element is 
retrieved and used in place of "%%./NUM". The query is 
executed and additional children elements are created, ^ 
expanding the hierarchy depth. The hierarchy can be end- 
lessly extended with ever-deeper children, each of which are 
replicated then executed. 
DDF Parameters 

In another aspect of a preferred embodiment of the 30 
invention, a DDF can define parameters for a Client's use, 
so that a Client can specify customization for a generated 
Data File. A DDF that generates customer account data, for 
example, may define a DDF parameter for customer phone 
number. The DDF parameter can be defined anywhere, but 35 
it is convenient to define a standard location, which we will 
call the INPUT element. This is an element in the document 
of Type INPUT, where attributes can be stored as DDF 
parameters. The input attribute is generally created as a 
template attribute at the time the DDF is created. .For 40 
example, the INPUT element of the customer account DDF 
may contain the attribute PHONE= 11 12223333. A Client 
may request the customer account DDF, and specify a 
parameter substitution "/INPUT. PHONE-71 95551212". 
Assuming the INPUT element is a root-level element, a 45 
processing engine would replace the value of the PHONE 
attribute with "7195551212" prior to executing any elements 
in the DDF. Execution would proceed, and presumably one 
or more executable elements would use a replacement 
operator referring to this input parameter. As an example, an 50 
SQL select statement might contain the reference 
%%/INPUT. PHONE in a where clause, thus selecting data 
for the appropriate customer. 

Several shortcuts are possible in parameter references. 
Input parameters could refer simply to attributes in the 55 
INPUT element. Thus, input parameter PHONE- 
7195551212 is equivalent to "/INPUT.PHONE- 
7195551212", and the replacement reference 
%%/INPUT.PHONE can be shortened to %%PHONE. 
Data File Formatting so 

In another aspect of a preferred embodiment of the 
invention, after a DDF is fully executed, remaining elements 
are output using customized formatting options. A system 
parameter file contains formatting commands for each type 
of element Style. The formatting occurs by processing each 65 
element recursively, and applying the formatting commands 
specific to the element's Style. 
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Domains 

Available formatting styles are grouped into Domains. A 
Style indicator can reside in several Domains, with each 
Domain defining a different format for the Style. Thus, 
selecting a Domain specifies the output format of the DDF. 
A DDF can specify a default Domain for generated Data 
Files by specifying the Domain in the GEN_TYPE 
attribute. This attribute is generally in the first element in the 
document, though it does not need to be. A Client may 
request a specific output format by setting the GEN_TYPE 
attribute in a parameter specification. 
Hierarchical Data Server 

In another aspect of a preferred embodiment of the 
invention, a computer system is capable of receiving 
requests for data files. Each request for a data file includes 
a reference to a DDF, plus parameters. The Server receives 
the request, reads the DDF into memory, and performs 
parameter substitutions for any parameter supplied by the 
Client. The Server then visits each element in the DDF, first 
performing replacement for any replacement operation 
(references preceded by "%%"), then executing the element 
if possible. Elements are recursively processed. After 
completion of all execution, processing occurs for format- 
ting and output. All elements are again visited, and output 
according to formatting commands based on the indicated 
Style of the element and the DDF's Domain. The fully 
processed output is then returned to the Client. 

The Server in this example is called a Hierarchical Data 
Server, or HDS. 

Document Definition Authoring System 

The job of creating DDFs can be very complex in the 
enterprise environment. To assist in creation and editing of 
DDF, the present invention specifies a computer system that 
assists a human in constructing DDFs. This computer system 
is called a Document Definition Authoring System 
(hereinafter referred to as Authoring System). 

FIG. 4a shows a preferred implementation of the Author- 
ing System. FIG. 4a shows the DDF named join.itd. The top 
window panel shows a graphical tree representation of the 
document which is constructed using the Microsoft Foun- 
dation Classes CTreeCtl class. The elements include an 
element of Type "XML" that generates an XML header for 
the file, an Input element that lists the parameters and values 
for the document, a Database element that defines the data 
source for all subsequent statements, and a PROBLEM 
element. The PROBLEM element has two children 
elements, each containing an SQL select statement. 

The lower portion of the window shows the same DDF in 
XML format. This panel is not modifiable. 

The View menu includes an option, "Expand 
Expressions", which executes the elements to produce the 
resulting Data File. The option File/Export performs this 
function also, storing the results to a file. View/Expand 
Expressions option produces the results as shown in FIG. 4b. 

Appropriate commands are supplied to insert new ele- 
ments at a selected location, edit existing elements, delete 
elements, and drag and drop elements to new locations. 

FIG. 4c displays the input form used for creating and 
editing elements. The Style, Type, Value, and Attributes 
fields correspond to components of the element as described 
earlier. The Item field is a synonym (readable label) for the 
Type, which can be defined in the system parameter file, for 
example, FIG. 5, lines 202-203. The Settings box displays 
the Execution Type selection that populates the EXEC 
attribute, and the Invisible flag, which, when checked, 
causes the introduction of attribute VISIBLE=NO. The 
button labeled "File ..." allows the navigation and selection 
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of a file, whose full path will then be supplied in the Value 
field. The button labeled "SQL ..." initiates the display of 
the helper form in FIG. 4d, which assists in the construction 
of an SQL statement. 

Children of an element are established by creating a new 
element as a child of an existing element. The user first 
selects the parent element, then selects a menu option to 
insert a child element. 

FIG. 4a displays an icon next to each element. This icon 
is associated with the element Type in the system parameter 
file, as in FIG. 5, line 202. A preferred embodiment also 
allows the user to specify an icon that is externally 
generated, in which case the icon's file name would be 
specified by the attribute FILENAME in FIG. 5, line 202, 
instead of an internal ICON_JNDEX. 

A complete set of operations in a preferred embodiment of 
the invention would include these operations: 



Command Available when clicked on Operation 



15 



[nsert Root 

Element 

Edit 

Delete 
Insert Child 



Empty space in left panel 



Element Icon 



Element Icon 
Element Icon 



Insert Before Element Icon 



Insert After Element Icon 



Create a new root level 
element 

Edit the type, value, and 
attributes of an element 
Deletes the selected element 
Create a child of the selected 
clement 

Create an element, place it 
before the selected clement. 
Create an element, place it 
after the selected element. 
Move the selected element to 
make it a child of the element 
directly above the selected 
element 

Move the selected element, 
removing it as a child element 
and making it a sibling of its 
previous parent. 

Drag & Drop Click and Drag an Element Repositions the element to a 
Icon different location in the tree 



Indent 



Outdent 



Element Icon 



Element Icon 



software. The ability to use a free parser and free or 
inexpensive DOM leads to drastically reduced development 
costs for clients, as the Parsing Code 6 component of an 
interface no longer needs to be developed. 

In another aspect of a preferred embodiment of the 
invention, the Hierarchical Data Server provides the ability 
to interface to a plurality of dynamic data source types. As 
examples, the following dynamic data source types are 
supported: 

1. Open Database Connectivity (ODBC) data sources for 
any ODBC-compliant data source supporting SQL; 

2. Microsoft Data Access Objects and Microsoft JET 
engine, supporting SQL interfaces; 

3. Microsoft ActiveX Data Objects, supporting a multi- 
tude of data sources; 

4. Command line program interface that allows a DDF 
element to run any program and read and format the 
result into the Data File. 

Each type of dynamic data source is known by an indi- 
20 cator called an EXEC type. The available EXEC types are 
listed in the system parameter file. When the HDS processes 
a DDF, each element that specifies an EXEC type as an 
attribute is executed using the specified EXEC type. 
In addition, new dynamic data sources can be defined, and 
25 code to implement the interface imported into the Hierar- 
chical Data Server using dynamically loaded code modules. 
A corresponding EXEC type must be appropriately placed in 
the system parameter file, and the DDF element data 
required in the interface must be specified so that the correct 
30 information can be passed to the Request Code 4 compo- 
nent. In this way, an enterprise can implement the Request 
Code 4 and Server Description Code 6 a single time in the 
Hierarchical Data Server. All clients needing data from a 
server requiring the new interface would request the data 
35 from the Hierarchical Data Server and receive the resulting 
data in any supported format. Thus, clients in the enterprise 
use a standard Parser Code 5 component instead of writing 
new interface code components specific to their interface 
with the Server in question. 

The ability of the Hierarchical Data Server to support new 
interfaces should not be understated. Revisiting the example 
of FIG. 3, the Parser Code 5 is now identical for each Client, 
and the Request Code 4 and Server Description Code 6 is 
moved to the Hierarchical Data Server and is no longer 



40 



XML Support 

In another aspect of a preferred embodiment of the 
invention, both the DDF and the Data File follow the syntax 
rules of Extensible Markup Language (XML), a standard 
published by the World Wide Web Consortium. Elements in 
the XML document representing a DDF can be static or 45 developed in the Client. Thus, Request Code 4 and Server 
dynamic. When a client requests a document from a server, Description Code 6 is developed once for each Server for a 
it references the appropriate DDF that is accessible from the total of 8 components, plus the Parser Code 5 is developed 
Server, and passes the server any appropriate input param- orice for both clients for a total of 8 developed components, 
eters. The DDF is copied, parameter substitutions applied, a dramatic savings over the 22 development components in 
and elements are executed to generate or retrieve the data for 50 alternate strategies. 



each element. Some of these elements may be XML links to 
other XML documents and/or elements. These external 
XML components may themselves be either static or 
dynamic, and are treated appropriately before incorporation 
into the resulting DF. 

In another aspect of a preferred embodiment of the 
invention, one of the Hierarchical Data Server's defined 
Domains is XML. Consistent with the formatting features 



In another aspect of a preferred embodiment of the 
invention, a Client can request a complex Data File from the 
Hierarchical Data Server in which a plurality of dynamic 
elements reference data generated data within the Data File. 
For example, DDF element A may instruct the HDS to 
generate a list of rows from a DBMS, which the HDS 
incorporates as Data File elements. DDF element B may 
reference the said Data File elements, using selected ele- 
ments as key parameters in its generation step. Generated 



mentioned previously, the Data Server can thus dynamically 

generate XML files on behalf of clients. Clients using the 60 data from one DDF element. 

XML domain can exploit the rapidly growing number of Filtering Data File Output 

software tools designed to work with XML. For example, In another aspect of a preferred embodiment of the 

XML parsers are available free of charge on the World Wide invention, certain attributes in the DDF element control 

Web, and the W3C Document Object Model, a software whether the resulting elements are included in the output 

component also widely available and built into the Microsoft 65 Data File. The attribute "INCLUDE", when set to "NO", 

Internet Explorer version 5.0, enable a Client to navigate directs the HDS to exclude the element from the generated 

through the returned Data File using industry standard Data File. The element is neither executed nor formatted. 
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Generally, the attribute would not be set to the literal "NO" 
in the DDR Instead, it would be set to a replacement 
reference that would be substituted based on a Client- 
supplied parameter. For example, an input parameter named 
"DETAIL" might be referenced by an executable element in 5 
the DDF by including the attribute "INCLUDE^ 
%%DETA1L". A Client wishing the element to be executed 
and included would pass the parameter "DETAIL=YES". A 
Client wishing to exclude the element would pass the 
parameter "DETAIL-NO". 10 

In addition, the attributes SWITCH and CASE allow 
clients to select one of a number of elements to execute and 
include in the output. When the HDS processes an element 
with attribute CASE, it checks the attribute's value and 
compares it with the value of the attribute SWITCH in the 15 
element's parent. If the values match, the element is 
executed and included. Otherwise, it is discarded as in the 
case of attribute "INCLUDE=NO". The value of the 
SWITCH attribute would likely be a replacement reference, 
so that a Client could select the desired element to execute 2Q 
by setting an input parameter, similar to the INCLUDE 
example above. 

The VISIBLE attribute controls whether an element is 
included in the output after execution. A value of VISIBLE= 
NO directs the HDS to execute the element as normal, yet ^ 
do not display the resulting element. Children of the 
element, whether generated via execution or not, are not 
affected by this attribute. 
Multi- threaded Execution 

In another aspect of a preferred embodiment of the 30 
invention, the execution of elements is carried out in mul- 
tiple threads. For an element having executable children, 
setting an attribute CHILDREN_THREADS=YES directs 
the HDS to spawn a new thread for each child. Each child 
executes to completion in the thread. The HDS waits for all 35 
children threads to execute prior to finishing processing for 
the parent. 
Joins 

In another aspect of a preferred embodiment of the 
invention, two or more elements can be joined together in ^ 
the same sense as a database join. When an element specifies 
the attribute JOIN-YES, or when the predefined element 
Type is JOIN, the children of the element are joined together. 
When a Join is specified, children elements in Set/Row/ 
Column format will be joined together into a single set, 45 
which replaces this element. Set/Row/Column format is 
described as follows: 

Using the Authoring System, document elements are 
often generated from database sources. Since databases 
generally return rows of data, the format of elements are 50 
very consistent. A database query returns a set of rows, and 
each row contains a number of columns. When retrieved into 
an Info Tree Document, this consistent format is called the 
Set/Row/Column format. In XML format, an example looks 
like this: 

<ORDERS_COMPLETE> 
<ORDER> 

<ORD_CD>0000000026</> 
<SSN>111223333</> 
<SALES_REP> 
<FlRST>Kirstan</> 
<LAST>Vandersluis</> 
</> 

</> 

<ORDER> 

<ORD_CD>0000000044</> 
<SSN>111223333</> 



55 



65 



<SALES_REP> 
<FIRST>Kirstan</> 
<LAST> Vande rslu is </> 

</> 
</> 

<ORDER> 

<ORD_CD>0000000045</> 
<SSN>111223333</> 
<SALES_REP> 
<FIRST>Kirstan</> 
<LAST>Vandersluis</> 
</> 
</> 
</> 

The ORDERS_COMPLETE element follows the general 
sure called Set/Row/Column, which is roughly equivalent to 
a database table. An InfoTree document can contain many 
such sets, and in this sense can represent an entire database. 
InfoTree provides operations on Set elements very similar to 
SQL commands on database tables. Data from elements with 
this structure can also be joined (see JOIN__KEY f JOIN_ 
SET, JOIN_LABEL attributes) with each other, or with any 
other element with a similar structure, namely elements 
generated from other database tables. 

The HDS operations on Set/Row/Column structures allow 
the HDS to manipulate data from many different system, 
regardless of the native format of the data. Multiple enter- 
prise data sources can provide data that can then be joined, 
selected, and filtered in a myriad of ways. 

Note that the Set/Row/Column format is not restricted to 
a single, simple element at the Column level. As in the case 
of SALES_REP above, a column element may have 
subelements, and in fact can be arbitrarily complex. 

The Join operation references a JOIN_KEY attribute, 
which specifies the element Type on which to Join. The 
above example can be joined with another set of element 
data. For example, assume another element set specifies 
phone numbers of sales representatives. A portion of the data 
may look like this: 
<PHONE_BOOK> 

<REP> 

<SSN>111223333</SSN> 
<PHONE>71 95551212</PHONE> 

</REP> 

<REP> 

<SSN>777334444</SSN> - 
<PHONE>3035551212</PHONE> 
</REP> 

Specifying JOIN_KEY=SSN directs the HDS to com- 
bine the sets into a single set, resulting in the PHONE 
element being copied into the ORDER set as follows: 
<ORDERS_COMPLETE> 
<ORDER> 

<ORD_CD>0000000026</> 
<SSN>111223333</> 
<PHONE>7195551212</PHONE> 
<SALES_REP> 
<FIRST>Kirstan</> 
<LAST>Vandersluis</> 

</> 
</> 

<ORDER> 

<ORD„CD>0000000044</> 

<SSN>111223333</> 

<PHONE>7195551212</PHONE> 
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<SALES„REP> 

<FIRST>Kirstan</> 

<LAST>Vandershiis</> 
<l> 
</> 

<ORDER> 

<ORD__CD>0000000045</> 
<SSN>111223333</> 
<PHONE>719555l212</PHONE> 
<SALES_REP> 

<FIRST>Kirstan</> 

<LAST>Vandersluis</> 

<l> 
</> 
</> 

The Join operation can be performed on any number of 
children. For a more detailed specification of the Join 
Specification, see FIG. 13, Join Code. 
Element Attributes 

Many processing commands are controlled by element 
attributes. The form for an attribute is: 

ATTRI BUTE = VALUE 

Where ATTRIBUTE is the name of the attribute from the 
table below, and VALUE is a string value enclosed in single 
or double quotes. 

A list of supported attributes follows: 



Description 



EXEC 



JOIN_LABEL 

JOIN_TYPE 

ROW_TAG 

COL_TAG 

COL_TAGS 

JOIN_JCEY 



[f present, this element is dynamic. This 
attribute designates the execution type (SQL, 
ActiveX, Join, Shell, ADO). SQL takes an 
SQL statement from the Value field and 
executes it. The target data source of the SQL 
statement must be specified by a 
DBDEFINlTION element somewhere in the 
document. The default DBDEFINlTION is the 
first instance in the sequence of parent 
elements, oi any sibling element of a parent. 
Alternatively, the DBNAME attribute specifies 
the ID of DBDEFINTTON element. ActiveX 
invokes an ActiveX control to generate data. 
Join performs a database Join on the children 
elements. Command executes a shell command 
to generate data. Sheli takes a shell command 
as the value, executes it using its stdout as data. 
Designates the Type tag to use for resulting 
element sets from a Join 
Performs either an Inner or Outer join on the 
children elements 

The Type tag to use in generated row data for 
SQL rows or lines of data generated by a Shell 
Command. 

The Type tag to use in generated column data 
for SQL columns, or token data generated from 
a Shell Command. 

A list of Type Tags to be used to tag columns 
returned from an SQL statement or for tokens 
generated by a Shell Command. 
The Type tag to look for which defines the 
element sets to join. When the Value field of 
the appropriately tagged subelements are equal, 
the elements are joined to form a single 
element in the result set 
Determines whether the element is visible in 
the resulting document (default is "YES"). If 
this is "CONTENT_ONLY", the value of the 
element is transferred to the resulting 
document, but not the attributes or element type 
data. 
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Attribute 



Description 



5 COL_SEPA RATOR 
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DBTYPE 
DBNAME 

HTML„COL_TAGS 

COL_LABELS 

SORT_J3Y 



25 



30 



CHILDREN_THREAD 
SKIP 



SWITCH 



35 



40 



45 



CASE 
IMPORT 



IMPORT_TYPE 
PARSE 



50 



HIDE_ VALUE 



55 



For SQL elements, designates a separator 
character between columns. If this attribute is 
present, the columns do not have their own 
start and end tags. The column data is instead 
separated by this character. For shell- genera ted 
elements, this character string designates the 
separation between tokens, each of which will 
become elements. If this is " " (single space), 
then parsing removes excess white space 
between tokens. 

Type of the database: ODBC, DAO (Data 
Access Objects), ADO (Active Data Objects), 
XML (Extensible Markup Language), ITD 
(InfoTree DDF) 

Reference to an element that defines the data 
source. This is the ID of the DBDEFINTTON 
element defining the data source. 
Specifies the tags to generate column headings 
in an HTML generated table, 
list of labels, separated by 'j\ designating the 
column header for the HTML table. 
Designates sorting criteria for a 
Set/Row/Column formatted element. Lists the 
column tag and optionally whether the sort is 
ascending (ASC) or decending (DEC). 
Example: SORT_BY-"ORDER_CD ASC". 
Multiple sort criteria can be applied in order of 
significance, by including more than one 
SORT_BY attribute. 

Designates whether children of this clement are 
expanded in parallel. 

Designates whether this element is skipped. If 
"YES", this element is not expanded, and is 
treated as invisible. The resulting InfoTree 
document behaves as though this clement does 
not exist 

Controls the generation of children elements. 
The value of the SWITCH attribute selects the 
children elements which are executed. Any 
child element with a CASE attribute equal to 
the value of the SWITCH element will be 
expanded. All others will be skipped, as if the 
SKIP attribute is set to YES. 
Controls the generation of children elements. 
Specifies the URL of a file to import into this 
element. This element is replaced by the root 
designated by the value of this attribute, which 
may contain an element reference (separated 
by#). 

Specifies the type of resource to import. Values 
are XML or ITD 

For Shell command elements, determines 
whether the command output is parsed (the 
default) according to ROW_TAG (per output 
line), COL_TAG or COL_TAGS (per 
"column"). If set to "NO", the output of the 
shell command is used as the text for the 
element. If set to "XML", the internal XML 
parser is run with the output of the shell 
command, and the output is parsed into DDF 
format. 

This attribute indicates that the generated 
output element will not include the element's 
value. 



A preferred embodiment of the invention recognizes 
several special elements Types. These elements, when 
processed, cause useful effects as described below. 



Element Item Element Type Description 



Database 



DBDEFINlTION Defines a Data Source to be used in 
SQL executions 
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Element Item 


Element Type 


Description 


Input 


INPUT 


Defines a list of parameters for the 
document. A document generally has 
at most one element of this type. A 
client requests a document by 
specifying the DDF and a 
replacement INPUT element. The 
supplied INPUT element is used to 
replace variables in the document. 


Join Children 


DBJOIN 


Specifies that children elements in 
Set/Row/Column format will be . 
joined together into a single set, 
which replaces this element. 


General 


GENERAL 


A generic element type that can be 
used to house any static or dynamic 
attributes, values, and children. 



Operation of Invention 

FIG. 6 shows a flowchart of the HDS portion of the 
preferred embodiment of the present invention. The HDS 
begins execution as a computer program by performing a 
System Initialization step 30 in which the program is loaded 
and initialized. During this step, the System Parameter file, 
FIG. 5, is read into memory for use during execution of the 
HDS. The HDS then awaits and accepts requests 31 from 
Clients. Communication between Client and Server can 
occur using any available mechanism, for example HTTP. 
Requests include a name to uniquely identify the DDF, plus 
a plurality of parameters appropriate for the DDF, each set 
according to the needs of the Client. Once the full request is 
received, the HDS reads the full DDF into memory 32, and 
performs parameter substitution in memory 33. Each param- 
eter includes a reference to an element component in the 
DDF, plus a value to replace in the form <reference>- 
<value>. Parameter substitution is performed in part by 
using the mechanisms of FIG. 14, Substitution Code. For 
each parameter, the reference is passed to GetTreeltemCom- 
plexPath 410, which returns a pointer to the appropriate 
element in the DDF. Note that an element is coded as a 
CTreeltem in the code examples. The pointer, now pointing 
to the desired element, provides access to the element. If the 
<reference> includes an attribute name, the attribute with 
that name in the element in question gets the <vahie> passed 
in. If no attribute name is part of the <reference>, the 
<value> is copied into the Value for the element in question. 
This process is repeated for each parameter. 

After parameter substitution, each top-level element in the 
DDF is processed 34 by a method to be described presently. 
Recall that a DDF is defined as a list of elements. The 
current process 34 simply calls the method Process Element 
37, FIG. 7, on each element in this list. Once processing is 
complete, the resulting data is formatted into a data file 35, 
using a process fully described in FIG. 9. Finally, the 
resulting Data File is returned to the Client. 

FIG. 7, Process Elements, describes the method of pro- 
cessing an element 37. First, Reference Substitution is 
performed 38 by the mechanism described in FIG. 14, 
Substitution Code. We then check for an IMPORT attribute 
in the element 39, and if so, we check the value of the Import 
Type attribute to see if it is XML 40, DDF 41, or some other 
supported custom type 42. As can be seen in FIG. 7, the 
element is processed appropriately 45, 46, 47 based on the 
value of this attribute. If the value indicates an unknown 
format, we don't import, but instead keep the element as is. 

We next perform conditional inclusion processing the 
INCLUDE, SWITCH, and CASE attributes at items 49, 50, 
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51, 52, and 53. Next, we determine if this element is 
executable 55 based on the value of the EXEC attribute, in 
which case we execute it appropriately as described by 56, 
57, 58, 59, 61, 62, 63. If the value of the EXEC attribute is 

5 SQL 56, we execute the element in the method described by 
FIG. 11, SQL BuildS ubtree, which builds and returns an 
element hierarchy that then replaces the current element. If 
the value of the EXEC attribute is COMMAND, we execute 
the element in the method described by FIG. 13, CMD 

10 BuildSubtree, which builds and returns an element hierarchy 
that then replaces the current element. This method can be 
extended by integrating other execution types 58 and 63. 
After execution of the element and replacement with the 
new element hierarchy, children of the original element are 

15 copied to each child of the new hierarchy. The copied 
children may be executable elements, and can reference the 
newly generated elements, as long as they have foreknowl- 
edge of the element names and structure. Finally, each child 
of the element, whether it was executed as just described, or 

20 not 60, is itself processed using the method of FIG. 8, 
Process Children. 

FIG. 8, Process Children, begins by checking whether the 
children are to be processed by parallel threads 65. If so, a 
new processing thread is created for each 66. Within the 

25 thread, Process Element 37 is called for the child element. 
Once all threads are running, the thread processing the 
parent element blocks 68, waiting for all threads to 
terminate, or until a timeout expires, at which point all child 
threads are done and we proceed with processing. 

30 If children threads are not requested 65, we sequentially 
call Process Element 37 for each child. Note that for both the 
multi-threaded and single- threaded cases, we are recursively 
calling Process Element 37, thus systematically processing 
our way through the element hierarchy in a depth-first 

35 sequence. After all elements are processed 69, we perform 
post-processing operations. In particular, we check for a Join 
request 70, and if requested, we join the plurality of children 
as described in 71. At this point we are done processing an 
element, and we may optionally remove all elements that 

40 have an attribute VISIBLE=NO. If we choose not to remove 
these elements here, we remove them later in the formatting 
procedure of FIG. 9. 

FIG. 9, Format Memory into Data File, first establishes 
the Domain of the format 76. Note that the Client may have 

45 specified the format in a parameter. We next prepare to 
iterate through the list of top-level elements 77, and for each 
top-top level element we find 78, call Output Element 79, 
whose method is described in FIG. 10. If no elements 
remain, we are done formatting 80. 

50 FIG. 10, Output Element, provides the mechanism to 
format and output the element to the Data File. We begin by 
determining the Style of the element based on the element's 
Style indicator and the current Domain. FIG. 5, System 
Parameter File, shows the format of example Domains and 

55 Styles. For example, Line 4 begins the Domain XML, which 
we will match if the current DDF's GEN_TYPE also is 
XML. The current element may have a Style of "ELEM", 
which we will match against the Style of Line 5. Line 6 
provides a formatting string. The formatting string is output 

eo to the Data File, with special tokens indicated by '%' being 
replaced by components of the elements. The following 
substitutions are performed: %T is replaced with the element 
Type, %V is replaced with the element Value, %A is 
replaced with the element's attribute list, each attribute 

65 constituting a key -value pair, and %C is replaced by the 
output of the children of this node. Note that here again, we 
recursively define a mechanism that will process and format 



05/20/2003, EAST Version: 1.03.0002 



us 6,3; 

19 

elements in a depth-first fashion. In the current example, our 
format string is "<%T%A>%V%C<?%T>". If our element 
Type is "ITEM", and we have one attribute NUM«1, and the 
element Value is "TABLE", the output would be "<ITEM 
NUM=1>TABLE</ITEM>". FIG. 10 describes this substi- 
tution in84, 87, 88, 89, 90, 91, 92, 93, 95, 96, 97, 98, 99, and 
100. Custom formats may also be processed as in 85 and 86. 
Elements that have attribute VISIBLE=NO are not output, 
but if %C is specified in the format string, the children 
elements are processed here as usual. 

FIG. 11, SQL BuildSubtree presents the mechanism for 
executing an element that has execution type EXEC-SQL. 
The SQL statement is taken from the element's Value field 
103. We then determine how to format the resulting rows 
104 and columns 105 in terms of element components. This 
means we need to determine the Type of the generated 
elements. Next, we secure the database connection 106 and 
open the connection 107 if it is not open already. Then we 
execute the SQL on the connection 108 and begin reading 
database rows 109. When we get a row 110, we create a new 
element as described in 106, then process the columns in the 
row 113 until there are no more. For each column 114, we 
create a new element, giving the element the Type as 
described by 115 and the value of the database column 117. 
We process all columns in the row in this manner until no 
more columns are available, then move to the next row 116. 
We process all rows as described above until no more are 
available, then we return the newly created element hierar- 
chy or subtree 111. 

FIG. 12, CMD BuildSubtree presents the mechanism for 
executing a command line program and formatting the 
results into an element hierarchy. We retrieve the command 
line program (also called shell program) from the element's 
Value field. We next check for the attribute PARSE 121, and 
if present, check if its value is XML 122. In this case, we run 
the command fine program, and feed its output into an XML 
parser 123, reading the resulting data into DDF format and 
returning it 124. If the value of the PARSE attribute is 
something else, we check to see if this is a request to run a 
custom parser (such as an SGML parser, or any other custom 
parser) 127, then we run the command line program and feed 
its output into the custom parser, which reads the resulting 
data into DDF format 128, which we return 129. 

If we did not find the PARSE attribute, we proceed with 
processing the element. We read the formatting commands 
as described in 125 and 126, which directs us how to create 
elements, and what the element Types will be. We then 
execute the command line program 130, and then read lines 
of data 131 as long as we can get another line. For each line 
we read, we create a new element as specified in 135, then 
we determine if we need to create column level elements 
based on the presence of the COL_TAGS or COL_TAG 
attributes 136. If not present, we set the new row elements 
Value to the value of the read line 133, then attempt to get 
the next line. If COL_TAGS or COL__TAG is present, we 
parse the line as space or comma delimited columns, creat- 
ing an element for each as specified in 138, 139, 140, and 
141. 

While the above descriptions contains many specificities, 
these should not be construed as limitations on the scope of 
the invention, but rather as an exemplification of one pre- 
ferred embodiment thereof. Many other variations are pos- 
sible. 

Accordingly, the scope of the invention should be deter- 
mined not by the embodiment illustrated, but by the 
appended claims and their legal equivalents. 
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What is claimed is: 

1. For a computer system interconnected to other com- 
puter systems on a network, a method comprising the 
computer-implemented steps of: 

5 (a) providing a means for defining a document definition 
file, which is identified by a unique name and is a 
hierarchically organized plurality of elements, each 
element comprising an element type, element value, 
and a list of child elements; 

10 (b) providing a means for processing requests from com- 
puter systems on the network, comprising the 
computer-implemented steps of: 

i. accepting a request for data from client systems, said 
request to include the identity of the document 
definition file, and plurality of parameters, said 

15 parameters each comprising a reference to an ele- 

ment in the document definition file and data; 

ii. copying said parameter data into said referenced 
element; 

iii. visiting each element systematically, for each sub- 
20 stituting referenced element components with the 

actual value contained in said referenced element 
component, then performing a specified operation 
defined by said element; 

iv. transmitting the resulting data to the client; 

25 (c) whereby a client computer system sends a request to 
said computer system identifying the document defi- 
nition file and input parameters, and the computer 
system reads the identified document definition file, 
applies input parameters to said document definition 

30 file, performs operations on every element of said 
document definition file, and returns the resulting data 
set to the requesting client. 

2. The method of claim 1, wherein the method further 
comprises the steps of providing the capability to define in 

35 a graphical tree -based visual environment the format, 
content, instructions for fetching and/or generating data 
elements, and parameters available to vary the data depend- 
ing on specific needs of a requester, or client. 

3. The method of claim 1 in which specified operations 
40 defined by elements in the document definition file are 

structured query language (SQL) statements with substitut- 
able parameters in any clause of the SQL statement; the SQL 
is executed on a database management system that is speci- 
fied in same or referenced element; the data returned as a 
45 result of the SQL statement is formatted into new elements 
and incorporated into the document definition file, available 
to be referenced by operations in same or other elements. 

4. The method of claim 3 wherein said new elements 
themselves inherit any child elements of the original ele- 

50 ment; the inherited child elements may specify operations 
that reference any original or newly generated elements. 

5. The method of claim 1 wherein the method further 
comprises the steps of providing a computer system Server 
to build a data file (DF) given the document definition file or 

55 the identification of the document definition file and a set of 
parameters used for replacement within the document defi- 
nition file; the computer system_Server copies the docu- 
ment definition file into a coupled memory, performs param- 
eter substitution throughout the document by replacing 

so instances of defined parameters with corresponding actual 
parameters passed in by the client, executes dynamic data 
elements to replace such elements with dynamic data, then 
performs formatting according to a format selected by the 
requestor; the resulting file in memory is transferred to the 

65 requesting client system. 

6. The method of claim 1 wherein the method further 
comprises the steps of providing elements in the document 
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definition file include operations executed by ActiveX or 
other software programs external to the computer system 
Server. 

7. The method of claim 1 wherein the method further 
comprises the steps of providing elements in the document 
definition file are commands that can be executed on a 
computer system command line, such as that provided by an 
MS-DOS shell, Unix shell (e.g. csh, sh, ksh). 

8. The method of claim 1 wherein the method further 
comprises the steps of providing document definition file 
parameters that are first defined by a reference to an element 
or element component, and corresponding value; references 
to the same element or element component throughout the 
document definition file are replaced by the parameter's 
value prior to the execution of any operation. 

9. The method of claim 1 wherein the method further 
comprises the steps of providing attributes which control 
certain aspects of generation of data, such as removing an 
element entirely from the resulting hierarchy, effectively 
moving the element's children up the hierarchy one level, or 
excluding the processing of the element altogether, and 
providing the ability of the requester to vary this behavior on 
each request for the same document definition file. 

10. The method of claim 1 wherein the method further 
comprises the steps of providing XML or its variants or 
subsets to be used as the format for the document definition 
file and/or the resulting data file. 

11. The method of claim 1 wherein the method further 
comprises the steps of providing SGML or its variants or 
subsets to be used as the format for the document definition 
file and/or the resulting data file. 

12. The method of claim 1 wherein the method further 
comprises the steps of providing the document definition file 
that is formally defined as a list of elements, where each said 
element is defined as containing the following: a) Type, a 
character string naming the type of the element b) Attribute 
List, containing zero or more associations between one 
character string as the name of the attribute, and anther 
character string as the value of the attribute, c) text data with 
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zero or more characters, d) a Style identifier, indicating 
precise formatting instructions for outputing this element to 
a data file, and e) zero or more children elements in a 
hierarchical relationship. 

13. The method of claim 12 wherein the method further 
comprises the steps of providing elements containing sub- 
stitution parameters in any portion of it, in which case the 
resulting element is produced by performing the appropriate 
key/value substitution; said elements fall into two broad 
categories: dynamic and static, a dynamic elements are 
executable, and/or contain data that can be translated by the 
Server, including substitutable parameters and hierarchy 
modification commands; hierarchy modification commands 
include the ability of an element to collapse itself so that its 
children are moved up one position in the hierarchy, and the 
ability to create new elements in the hierarchy by reformat- 
ting its data or the data of its children; said element may be 
a dynamic element, in which case it must be executed in 
order to produce its data. 

14. The method of claim 13 wherein the method further 
comprises the steps of providing augmented display infor- 
mation so that a client may more easily display the infor- 
mation; said augmentation to include screen identifier; 
screen position; label name; field edit, format and validation 
commands such as a regular expression as used by the Unix 
"grep" command; and any other rendering information such 
that the document definition file specifies completely both 
the data definition and screen rendering attributes; whereby 
a single computer program can be used by a plurality of 
diverse applications, and these applications having knowl- 
edge only of the document definition file and parameters 
appropriate to the document definition file can render a 
display of the information. 

15. The method of claim 14 wherein the method further 
comprises the steps of providing display rendering of data 
files, wherein the client is an application running within a 
world wide web browser. 
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